A HOL Basis for Reasoning about Functional Programs

ion: The input term has the form "\x :: Dom D. e[x]" (x could be a pair). Add (x,D) to the database while parsing e[x] recursively, obtaining the result "(e’[x],E)". Return the pair ("lambda D(\x. e’[x])","cf(D,E)"). Strictly speaking, this is not a valid inference since a lambda abstraction need not be continuous just because it maps elements of its domain D to elements of its codomain E (see how the type checker handles lambda abstractions). However, when e[x] meets the syntactic notation, this is valid. Also note that the restricted abstraction is transformed into the lambda abstraction, a secondary purpose of the parser. If something goes wrong in a call to the algorithm, then it returns a certain dummy domain to indicate this. The user will usually realize this when the type checker fails (only sometimes the parser fails in such a situation). 5.2.2 Algorithm for Type Checking The type checker takes a term t of the internal syntactic notation as input and reconstructs the domain of the term in the sense that it constructs a cpo D and proves |t ins D . A rough sketch of the algorithm can be presented as follows, by cases on the structure of the input term: Constant/variable/any term: Find (if possible) and return a theorem in a database of cpo membership facts stating that the input term is in some cpo. For instance, the theorem could be |$+ ins cf(Nat,cf(Nat,Nat)), or indeed |t ins D for any term t and domain D . Parameterized function constructor: Input has the form "FunI(D1’,. . .,Dn’)" for some function constructor FunI . Find FunI in a database of facts of the form |cpo D1 ==> ... ==> cpo Dn ==> FunI(D1,...,Dn) ins cf(...,...) where D1 , . . . , Dn are variables. Instantiate these variables with D1’ , . . . , Dn’ respectively, prove the cpo (or pointed cpo) assumptions using the cpo (or pcpo) prover and return |FunI(D1’,. . .,Dn’) ins cf(. . .,. . .) . Pair: The input term has the form "(t,u)". Apply the type checker recursively, obtaining |t ins D and |u ins E . Then, use the theorem (employ modus ponens) |!D1 D2 x y. x ins D1 ==> y ins D2 ==> (x,y) ins (prod(D1,D2)) to conclude and return |(t,u) ins prod(D,E) . Combination The input term has the form "(t u)". Apply the type checker recursively, obtaining |t ins cf(D,E) and |u ins D . Then, use the theorem |!D1 D2 e1 e2. e1 ins (cf(D1,D2)) ==> e2 ins D1 ==> (e1 e2) ins D2 to conclude and return |(t u) ins E . Lambda abstraction: The input term has the form "lambda D(\x. e[x])" (which is not considered to be a combination). This is the difficult case! Ideally, we would like a theorem stating "v ins D1 ==> f(v) ins D2 ==> (lambda D1 f) ins cf(D1,D2)", but this does not hold; the lambda abstraction is not necessarily continuous (nor monotonic). Instead we must proceed according to the term structure of the body of the abstraction. The local recursive algorithm for this pushes the abstraction into the body in recursive calls and pulls back continuity. The local algorithm can be described as follows, by cases on the structure of the body of the abstraction: Constant term: The body e[x] does not contain the variable x of the abstraction and the theorem |e ins E is in the database of cpo membership facts (otherwise try to destruct e[x] further). Prove D and E are cpos (using the cpo prover) and use the theorem (employ modus ponens) |!D0 D1 e. cpo D0 ==> cpo D1 ==> e ins D1 ==> (lambda D0(\v. e)) ins (cf(D0,D1)) to conclude and return |(lambda D(\x. e[x])) ins cf(D,E). Variable: The body e[x] equals the variable of the abstraction x . Prove D is a cpo and return |(lambda D(\x. e[x])) ins cf(D,D), using |!D0. cpo D0 ==> (lambda D0(\v. v)) ins (cf(D0,D0)) Pair: The body is a pair of the form "(e1[x],e2[x])". Apply the algorithm recursively on each component of the pair, obtaining |(lambda D(\x. e1[x])) ins cf(D,D1) |(lambda D(\x. e2[x])) ins cf(D,D2).